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(54) Title: SERVICE PROVISION IN COMMUNICATIONS NETWORKS 
(57) Abstract 

It is desirable in communications networks to be able to offer a variety of services to the customer, and to be able to add or modify 
the portfolio of services available. A service delivery infrastructure (21) is provided, which would sit in the Service Control Point of 
an 'nfelhgent network architecture, and which delivers services using an array of service independent features (20). In the arrangement 
described, the service delivery infrastructure (21) has an object oriented architecture and interacts with systems, such as billing (22) and 
network management (40), in the communications network by means of objects within the mrrastructure (21). An aspect of the mfrastructure 
(21) is the provision of selected sets of services to users of the communications network, which selected sets effectively provide dedicated 
service networks (30) to each customer. 
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SERVICE PROVISION IN COMMUNICATIONS NETWORKS 

The present invention relates to the provision of services over 
communications networks. If finds particular application in networks where 
5 intelligence, that is decision-making or data processing software, is provided 
elsewhere than in network transmission and switching apparatus, such as in networks 
having an "intelligent network" architecture for instance. 

In communications networks technology, an area which is fast evolving is that 
of providing a choice of services to network users. These services might be voice, 

10 data, video or multimedia-based for example and reply on different network 
capabilities. Increasingly, and more so in the future, services over a single network 
may be provided by several different service providers, and the network provider may 
be a different entity again. That is, the world of communications services, or 
information services, is growing much more flexible but also complex. 

15 It is desirable, particularly for the network operator but also for service 

providers, that services can be introduced quickly and flexibly, without undue delay or 
cost. Both the network operator and the service provider will need to be able to 
provide those services to customers as fast and as cheaply as can be achieved. 

A development in recent years, in the switched telecommunications 

20 environment, has been the provision of intelligence in communications networks 
which lies elsewhere in the network architecture than in the switches, or exchanges, 
for switching traffic in the network. This allows much improved flexibility in service 
provision, since it is no longer necessary to update all the network switches to instal a 
new service, but still only goes as far as laying a basis for developments in service 

25 provision. The infrastructure needed to deal with not only technical support for a new 
service, such as number translation facilities or transmission bandwidth, but also 
management aspects, such as billing and charging, and order handling, is still a major 
challenge. 
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Figure 1 shows schematically a basic intelligent 
network (IN) model. The transmission network 100 connects 
customer premises equipment (CPE) IDS by means of switches 
110. However, above the transmission network level, there is 
5 the service control level, incorporating Service Control 
Points (SCPsj 115, and above that again comes the service 
management level, incorporating a Service Manaaeraent Svstem 
(SMS) 120. 

The IN equipment is used to provide services over and 
10 above basic telephony, this being provided by. means of the 
transmission network as of old. The IN type services, such 
as those based on number translation, are provided 
differently. 

Each switch 110 incorporates a Service Switching Point 
15 (SSP). When a call comes into a switch 110 from CPE 105, the 
Service Switching Point is used to pick out calls identified 
as needing Intelligent Network services. it does this by 
reference to trigger tables in the SSP. If the call is an 
IN call, „ h i ch will usually be identified by the associated 
20 destination number, the SSP in the switch 110 triggers 
intelligent processing by passing a request to an SCP 115. 
The processing of the numbers which do not trigger at the SSP 
in the switch no proceed to be routed and carried by the 
transmission network 100 as in the past. 
25 on receipt of a request, an SCP 115 uses call -related 

information, usually the destination number, to locate 
service logic which it then executes. This service logic 
execution is done in a "Service Logic Execution Environment" 
or SLEE. in the SCP. A Service Data Point (SOP) 125 is used 
30 by the SCP U5 for information it needs in processing. After 
execution of the service logic, the SCP 115 passes control 
back to the switch 110 and the call proceeds, carried bv the 
transmission network 100 but now in accordance with the 
executed service logic. 
35 The introduction of the service logic has, to date 

most usually been to supply number translation and alteration 
of charging mechanisms. Number translation comes into nlav 
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when a dialled number is not the actual network destination 
number. For example, a Freephone (0800) number is not an 
actuai network destination number. It does though trigger 
SCP processing that will translate the dialled number into an 
5 actual number to be called. The service logic in this case 
will also change the charging mechanism in that it reverses 
the normal charging policy, so that the called party will 
receive a bill rather than the calling party. 

A Service Management System 120 is used to manage 
10 trigger tables in the SSP of the switch 110, the installation 
of service logic in the SCP 115, and the management of data 
in the SDP 125. 

This placement of service logic in an SCP 115 
effectively. takes sophistication out of transmission network 
15 switches 110. Since it is not necessary to have nearly as 
many SCPs _ 115 as there are switches 110 in the current 
British Public Switched Telecommunications Network (PSTN) 
100, this has the advantage of greatly decreasing the number 
of software modules which need to be modified to deploy or 
20 enhance IN services. 

Functionality in an Intelligent Network architecture 
can be provided from various software modules. For instance, 
an Intelligent Peripheral 130 might be used to provide simple 
resources directly to the switch 110, such as security checks 
25 on the use of Personal Identity Numbers. Another development 
has been provision of a Service Node 135, this itself 
incorporating a switch. Service Nodes 135 can provide 
relatively complex resource interactions. 

These functional blocks of equipment, the SCP 115, SMS 
30 120, Service Node 135 and Intelligent Peripheral 130, 
generally comprise computing platform 140 on which sit 
applications 145. The applications 145 are pieces of 
software by means of which the computing platform 140 is 
controlled to provide functions, via an Applications 
35 Programming Interface (API) 150. 

In practice, the service control level will be an 
information network in its own right and can be extremely 
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complex. Each SCP 115 may be connected to other SCPs 115. 
Tor instance, if a service is to be provided over what is 
geographically a wide area, for instance internationally, it 
is difficult to provide the service by means of only one SCP 
5 115. In such a case, an SCP 115 might be provided in each of 
several regions, for example in each country for an 
international service. The service data then has to be 
distributed to the databases of all these SCPs 115. Rather 
than using the transmission network 100, according to the 
10 intelligent network principle of separating service control 
from the transmission network 100, it will be preferred that 
inter-exchange (SSP-SSP) signalling should be independent of 
the services and should not therefore carry IN-based service- 
related information. Consequently, SCP-SCP communication 
15 will be needed for transfer of service-related information, 
tor example for number translation where the original SCP 115 
has no translation information. 

Functionality in an IN architecture can often 
optionally be provided from different places in the 
architecture. Looking at the SCP 115 and the service node 
135, the service applications 145 which dictate the services 
which in practice are available to a network user can be 
provided from either system. However, there remains the need 
ror services to be flexible and this has resulted in service 
25 creation facilities 160 taking on considerable significance. 

Known service creation techniques are based on the use 
of standard sets of service logic building blocks which can 
36 brcu 9ht together in different combinations to provide new 
or different services. These are then made available to 
30 users of the transmission network 100 usually by being 
compiled at the SC? 115. and managed by means of the Service 
Management System (SMS) 120. 

In particular, a Service Creation Environment 160 mav 
compose a set of software tools which can be used to create 
35 semce logic. The logic is then supplied to a Service Logic 
Execution Environment ( SLEE ) , to create the functionality for 
instance at the SCP 1 15 or the Service Node (SN) 135. 



20 
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This type of arrangement has considerably changed the 
communications business, at least in the telephony-based 
area, in that service creation is available and can be 
carried out not only by the software engineer but, in effect, 
5 by technically non-expert, for instance marketing, personnel. 
This is enabled by providing service creation facilities 160 
working at a "user-friendly" graphical user interface level, 
for instance based on icons or simple text statements which 
can be pulled into flow chart representations of service 
10 "mechanisms". The flow charts are however direct 

representations of service logic which can then be loaded at 
the SCP 115. 

The above describes the basic principles of service 
creation in known IN environments, wherein new services can 

15 be provided by pulling together standard building blocks from 
a portfolio of building blocks in relevant combinations. 

The technical area of the present invention is 
complementary to this type of service creation but is more 
'concerned with the deployment and delivery of services 

20 created, than with the creation process itself. As can be 
imagined from the above description of IN architectures, the 
complexity of services which can be made available to 
individual users, or to groups of users, is very great. 
There is an obvious need for infrastructure to support and 

25 manage service delivery, which can allow the service provider 
or user to take advantage of the flexibility of the 
developing service creation capabilities without also 
creating insurmountable difficulties in service management or 
access. 

30 According to a first aspect of the present invention, 

there is provided a service delivery system, for making 
services available over a communications network, where one 
or more services selected from a group of services is made 
available to at least one network user, wherein said service 

35 delivery system comprises service provision functionality 
dedicated to said at least one user, the functionality so 
dedicated comprising a service directory defining the one or 
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more selected services available to that user, and a number 
directory defining a virtual network dedicated to that user 
out of said communications network, within which the services 
or the service directory are available to that user. 

By structuring the service provision functionality 
accorcmg to dedicated virtual networks carryina dedicated 
service sets for respective users, it becomes relatively 
simple to allow new services to be made available to a user. 

Preferably, the service delivery system i s provided 
with a st ored array of service independent features 
sometimes referred to as "Generic Service Components" (GSCs) 
and means for accessing the service independent features to 
support provision of a service from a service directory, over 
a virtual network within which the service is available in 
1- response to a call instance relevant to the virtual network. 

Features in this context can be defined as reusable IN 
components used in the construction of a service. For 
instance, -Call Forward" is a feature in which a new 
destination is always generated and is clearly an IN service 

could? T eVer ' ^ "«« ° f the — destination, which 
could be a fax mail-box or another telephone for instance, is 
not determined until that feature is used in building a 
service. Hence the feature is independent of the particular 
service it might be applied in. 

" . USe ° f 3 St ° red ««V of service indeoendent 

features, accessible to support services on anv of the 
virtual networks, makes it particularly easy to add to and 
enhance the services which can be delivered by the system. 

30 and 1S ', St0r6d " ray bS Slmply ** ten <^ or amended 

and relevant service directories then undated when 

appropriate to add a service, for instance at user request 

this way, only a single set of service features needs to 
be changed,, rather than individual sets for each user or 
customer record. 

35 In erabodi * en " of the present invention, a process for 

Provioing a service by means of a communications network, in 
real time, might comprise receiving an initiating call from 



WO 95/23483 



PCT/GB95/00421 



a user which purports to initiate provision of. said service, 
verifying availability of relevant service independent 
features in the context of the initiating call by reference 
to a user profile, and using the service delivery system to 
5 respond to said initiating call in accordance with the 
outcome of said verification. 

Said verification and response can be carried out by 
means of a blackboard technique, said user profile calling on 
service independent features which each will register a view 
10 with the blackboard and, when triggered by that view, will 
process the view, plus any additional parameters, and post 
back resulting scenes on the blackboard so that subsequent 
interactions between features and the blackboard will be 
affected where appropriate by the preceding interaction. 
15 Features are "insulated" from the real physical world 

in embodiments of the present invention by working with 
logical representations. Features are assigned to profiles, 
each profile being a data package associated with a network 
operator, a customer or a user, and features are triggered in 
20 a novel manner by use of the blackboard technique, being 
managed overall by the application of rules. 

The principles of such a service creation and delivery 
environment can allow the network operator a high- degree of 
control and flexibility. Surprisingly, although blackboard 
25 techniques are known in the field of artificial intelligence 
(AI) as being too slow to transfer to complex systems, it has 
been found possible in embodiments of the present invention 
to limit the complexity "visible" to the blackboard process 
in a manner which overcomes the question of speed, in spite 
30 of the potential complexity relevant to any commercially 
competitive communications network. 

It has aiso been recognised in making the present 
invention that there can be a significant advantage in 
discerning between features and infrastructure in 
35 implementations. By separating features from infrastructure, 
communications networks, and the services available thereby, 
can be built to the customer' s specification by only 
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including features from a feature portfolio that are required 
rather than by inhibiting access to network functionality. 
In previous implementations, the features have in practice 
been so closely related to the basic network services that 
5 feature selection has affected both access to network 
functionality and physical architecture. 

A particular advantage of embodiments of the present 
invention is the independence of features, germane to service 
prevision, from physical network attributes. This means that 
10 service provision becomes decoupled from transmission 
technology and therefore for instance transportable from 
conventional to synchronous digital hierarchy (SDH) - based 
and asynchronous transfer mode (ATM) - based networks. 

A further aspect of embodiments of the present 
15 invention is that of dynamic replaceability, allowing new 
features to be added for any particular user, or to a 
particular network, without the need to interrupt service. 
This is facilitated, according to embodiments of the present 
invention, by a mechanism relying on a Service Delivery 
20 Infrastructure (SDI ) which provides the insulation of 
features from the complexities of the physical world 
mentioned above by working with logical representations of 
callers and stations. In particular, an SDI provides virtual 
networks to the user or customer by building in 
2 5 representations which take the form of Virtual Network 
Directory Numbers (VNDNs). 

An embodiment of the present invention will now be 
described, by way of example only, with reference to the 
accompanying Figures in which: 
30 Figure I shows, as mentioned above, a basic model of 

an intelligent network according to known network 
architectures ; 

Figure 2 shows the Service Delivery Infrastructure 
(SDI) in the context of external systems and IN services; 
25 Figure 3 shows a schematic representation of networks, 

real and logical, supporting the SDI of Figure 2; 
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Figure 4 shows the context: of the SDI of Figure 2 
amongst actual systems of a transmission network; 

Figure 5 shows elements of a transmission network as 
viewed by the SDI of Figure 2; 
5 Figure 5 shows a relationship between node addresses 

and network addresses in a physical network of the SDI of 
Figure 2; 

Figure 7 shows resource arbitration in a physical 
network of the SDI of Figure 2; 
10 Figure 5 shows the internal architecture of the SDI of 

Figure 2; 

Figure ? shows a graphical representation of 
scheduling of a directory number; 

Figure 10 shows SDI/system interfaces; 
15 .Figure 11 shows virtual network access to a service, 

in the SDI of Figure 2; 

Figure 12 shows the limited view a virtual network 
holds of the transmission network, via a Physical Network of 
"the SDI of Figure 2; 
20 Figure 12 shows an SDI context in terms of interfaces, 

internal and external to the SDI; 

Figure 14 shows a message diagram for the SDI of 
Figure 2; 

Figure 15 shows communications between resources using 
25 a transaction protocol of the SDI of Figure 2; 

Figure 16 shows a dialog composition using the 
transaction prctocol; 

Figure 17 shows the components of an inter-resource 
operation using the transaction protocol; 
30 Figure 13 shows the components of a leg in a cail 

expressed in the transaction protocol; 

Figure 19 shows the composition of "Physical Network 
Address", a component of the leg of Figure 18; 

Figure 20 shows a communication model for a SLEE 
3 5 supporting an SDI application; 

Figure 21 shows components of a DMSU as a Transport 
Network Resource using the transaction protocol; 
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Figure 22 shove components of a Speech Applications 
Platform as a Transport Network Resource using the 
transaction protocol; 

Figure 23 shows an event trace for profile retrieval 
5 by a Virtual Network; 

Figure 24 shows physical node discrimination by 
components of the SDI; 

Figure 25 shows a dictionary class interface for use 
in provision of persistent objects; 
10 Figure 26 shows a process control state transition 

diagram for processes run on a target platform to embody the 

Figure 27 shows a pictorial representation of steps 
carried out by the SDI and related applications in response 
15 to an incoming call, to trigger relevant features; 

Figures 28 to 43 show the compositions of the 
following software entities within the SDI of Figure 2: 
Transaction Protocol; 
Physical Network; 
20 Physical Node; 

Physical Node Directory; 
Resource Allocator; 
Virtual Network- 
Profile; 

25 Virtual Node Directory; 

Virtual Number Directory; 
Virtual Directory Numbers- 
Virtual Network Address; 
User Directory; 

30 Service Dictionary; 

Toll Ticket- 
Network Interconnect; 
Virtual Node; and 

Figures 44 to 48 show schematic flow diagrams for the 
following operations on or using the SDI; 
service creation; 
virtual network provisioning; 
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physical network /network interconnect provisioning; 
service (instance) provisioning; 
processing an incoming call. 

It might he useful to note in the following 
5 description that "virtual network" is a term used to describe 
a network effectively dedicated to use of a single customer, 
such as an international corporate entity, which appears to 
the user much as a private network would have appeared in the 
past, defined in dedicated hardware, but which is defined 
10 from a greater transmission capability usually simply by 
software. That is, the virtual network is only limited, for 
instance in geographical layout and in capacity, by a 
software specification, in accordance with the requirements 
of the customer, which specification allocates resources from 

15 a transmission network. 

For. instance, a network provider may have installed 
international voice and data carrying highways, 
interconnected by switches so that voice and data can be 
routed appropriately, which carry multiplexed traffic for 

20 multiple customers, each customer however only being able to 
access traffic which originates and terminates at their own 
Customer Premises Equipment (CPE). 

In embodiments of the present invention, each customer 
can not only choose to change the physical capacity available 

25 to them by means of a virtual network but can also, 
independently, choose to change the service portfolio 
available to them. For instance, a customer might already 
have available " time-of -day routing", in which incoming calls 
can be automatically rerouted after a particular time such as 

30 close of business away from individuals' offices to a number 
providing a recorded message. They might then decide they 
also need authorisation of outgoing calls to international 
destinations . 

In the following, object oriented software engineering 
35 terminology is used. In object oriented software systems, 
data and functionality are brought closely together in 
representations of real -world entities. The real -world 
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entity may be an article or a process for instance, an 
organisation or a booking procedure, but every real -world 
entity can be represented in the software system as an 
"object", that is a combination of data relating to the real- 
5 world entity, encapsulated in process -related software for 
accessing that data. The software implementing an object can 
thus be described as data structures together with operations 
that express the behaviour of the object, and the entity 
represented by the object is any thing, real or abstract, 
10 which one can describe in data plus operations to manipulate 
the data. 

SDI Internal Architecture 

Referring to Figure 8, overall the architecture of the 
15 SDI 200 itself is structured as follows: 

i ) an array of virtual networks 800; 

ii) one or more transmission (transport) network 
objects 805; 

iii ) a network interconnect object 810; 

20 iv > a library 815 of service independent features (or 

generic service components); 

v) one or more network operator's management network 
objects 820; and 

vi ) a service engine 825. 

25 This effectively provides the following: 

• virtual Encapsulation of physical transport 
networks ; 

• provision of customised communities of users and IN 
services over these abstracted transport networks - multiple 

30 virtual networks; 

• logical de-coupling of the overlay of Virtual 
Networks onto Transport Networks; 

• provision of libraries of Generic Service 
Components which can be utilised to dynamically create new IN 

35 services; 

• provision of a new interpretive program upon which 
these services execute; 
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o provision of a virtual encapsulation of management 
and support systems; 

• IN services within a virtual network can be 
provided on one or more transport networks where transport 
networks can be different telecommunications networks; 

0 provision of a commonly owned program interface to 
all components of the framework. 

Transport Network Abstrac tion 805 

The SDI transport network abstraction provides a 
virtual encapsulation in software of the topology of a 
physical network and of the networks elements' capabilities, 
protocols and call models. It manages the resources involved 
in a particular call within that particular network. 
15 As new elements wouid appear in the transport network, 

to be utilised by virtual networks or IN services, then new 
encapsulations of those elements would be brought into the 
appropriate transport network abstraction. 

Each network element encapsulation supports the common 
20 3T-owned interface into the SDI. 

Management MP tvork 820 

This component exhibits much the same encapsulation 
principles as the Transport Network but is more specifically 
25 representative of non-call processing entities such as credit 
bureaux, billing systems and other operational support 
systems. It provides virtual encapsulation of each 

particular system interface and protocol and offers a common 
interface into other SDI components. 

30 

Virtual Network flOO 

This is the powerful innovative technique of providing 
communities of users as a Virtual Network. The community 
specification is arbitrary and may be a complete 
3 5 telecommunications company, a corporate network or a group of 
disparate physical stations from one or more 
telecommunications networks. 
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The services available on a particular VN are defined 
within the scope of that VN. They are created using a BT- 
created syntax which identifies the components and running 
order of components in the Generic Service ComoonentJ 
5 Library. 

Users on a VN have specific identities and are 
configured, through service creation tools, to have access to 
particular configured instances of one or more of the 
available IN services. 
10 The instances of the services are deployed and 

configurable using service creation tools accessible from 
numerous interfaces such as human, telephony or operator 
assisted. 

15 Network T ntpypnnn qct 810 

This provides BT with the highly configurable 
robustness to provide a logical association to determine 
which nodes/stauons in the set of available transport 
networks constitute a virtual network. 
20 ™ S enabl es dynamic reconfiguration of the underlying 

physical implementation of virtual network bv the virtual 
network provider without the need to change the Virtual 
Network itself. Reasons for such change could be numerous 
examples being network outages, change of network orovider 
25 etc. 

Service Enp-np 

This is an innovative interpretive virtual processor 
upon which services execute. It relies on a "blackboard" 
30 software processing technique with limited feature sets to 
keep processing tines within acceptable limits for real time 
operation. 

Generic Serv:rP Comonn^- Lihr^r-y am 

35 This is the horary of components created and deployed 

as part of the service creation process that are available to 
be used for IN services. 



WO 95/23483 



PCT/GB95/00421 



- 15 - 

Any IN service within a VN 800 is specified in terms 
of these GSCs. 

Overall, an SDI 200 according to an embodiment of the 
present invention employs a number of innovative abstraction 
5 approaches to the delivery of IN services that, combined, 
exhibit an adroit capability to provide IN services within 
and across networks for a wide range of applications. 

1. REQUIREMENTS FOR SDI 

10 

Referring to Figure 2, the SDI 200 is required to be 
a real-time, IN element, software environment. It is 
intended that the interfaces with external elements are 
encapsulated and presented to the services 205 in a 
15 consistent logical manner. 

1. 1 System Architecture 

Referring to Figures 1 and 2, the SDI 200 resides on 
an Intelligent Network Element (e.g. SCP 115 or SN 135) which 
20 is within the ambit of a Service Creation Environment (SCE) 
115. The SDI 200 and the applications running under its 
auspices provide the call processing part of an IN service. 

The SDI 200 has transmission network interfaces 1010, 
primarily to the SSP 110, a service creation interface 1000, 
2 5 operations and management interfaces 1030 and a human/machine 
interface 1020 for a network operator user. 

The SDI 200 supports the establishment of multiple, 
discrete, service-less virtual networks to which services can 
be added. The SDI provides the basic service framework under 
30 which IN services operate, presenting common interfaces to 
management and billing systems. 

Each discrete virtual network 800 of the SDI 200 
should be configurable in terms of the services available on 
it, the users on it and the services available to each user. 
35 A virtual network can represent any classification of users, 
e. g. a corporate network or a particular subset of the public 
network. 
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The SDI receives all provisioning information through 
a provisioning interface, for instance from other systems in 
-he SCE 210. 

5 1. i. 1 Perfornar.ee & Dim ensioning 

A limited number, for instance one hundred and fifty, 
of virtual networks 300 may be defined. The number of users 
m each network may be configured but the total number of 
users for all networks will be limited, for instance to 
10 2,000,000. The SDI software downtime should also be limited, 
:or instance to not more than 2 minutes in any one year. 

For all services on the networks and services 
supported by the SDI, a reasonable target of calls handled 
per second in the busy hour might be 160 (576,000 BHCA). The 
15 response time to call messages received should be less than 
for instance 100 milliseconds for 98% of all messages at 80% 
loading. Full loading is considered to be the product of the 
average number of messages per call and the maximum number of 
busy hour call attempts. 



20 



1- 1- 2 Software Enoinep—nrr 

The SDI needs to be a real time application. The SDI 
and its interfaces have been developed using Object Oriented 
technology. The development needs to be portable and 
25 implemented by a set of re-usable modules. A suitable target 
platform might be based on Stratus hardware. 

1. 1. 3 Use and Usage R eouiremppr^ 

The SDI 200 can co-exist on the SCP or SN SLEE. In 
30 che following, it is described as being on the SN SLEE. The 
SDI design endeavours to re-use components of the SN SLEE 
where encapsulation ^akes engineering sense and offers 
acceptable delivery time-scales. 

SDI software upgrades need to be backward compatible, 
35 where the operating systems permit. By designing components 
to be dynamically replaceable, and other appropriate design 
principles, SDI upgrades need cause only short disruption to 
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service, for instance of no more than one minute (where no 
operating system or third party product is involved). It 
should be possible to roll -back out of upgrades to SDI 
components . 

1. 2 Types of Network 

Referring to Figures 3 and 8, in the following 
description of the present embodiment, there is one physical 
transmission network 100, which carries e. g voice traffic, 

10 upon which logical (virtual) networks 800 are constructed. 
The physical transmission network 100 can be. considered to 
comprise all the physical elements that make up the totality 
of the telecommunications network from transmission 
equipment, switches, cros s -connect points etc. 

15 Each virtual network 800 of the SDI 200 needs some 

logical means of addressing physical nodes 300 within the 
transmission network 100 to which its users are connected. 
Services are then built on the concept of virtual network 
directory numbers and users, rather than transmission network 

20 directory numbers and users in the transmission network 
context. 

The establishment and management of the transmission 
network 100 is handled in the network operations, planning 
and management domain of the network operator' s business. 

25 The provision of virtual network directory numbers is a step 
towards insulating the virtual network from the physical 
network topology. (There is further discussion of this area 
later in this specification. ) 

If the physical nodes 300 are to be addressed, the 

:0 physical name of the particular nodes need to be declared to 
the SDI 200. This physical information is localised within 
the SDI 200 as an SDI "Physical (or Transport) Network" 80 5. 
This is effectively then a projection of a small proportion 
of the transmission network 100, in the SDI 200, supporting 

25 the virtual (or "service") networks 800. Each virtual 
network 800 has associated with it only the nodes 300 in the 
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transmission network 100 required to connect users to that 
network. 

Referring to Figure 3, the SDI Physical Network 805 
also provides a logical representation of network 
5 capabilities. Virtual Networks 800 then logically group SDI 
Physical Network nodes 305 together with services. Virtual 
networks 800 provide services to Customers. Each customer 
has only the top-level view - a dedicated virtual network 800 
of services. 

10 Based on the above, the following passages are: 

• Section 1.3: " SDI Physical Network" 805 - 

covers the requirements of representing that part of the 
Transmission network that is required to deliver IN services. 

• Section 1.4: "Virtual Networks" 800 - covers the 
15 requirements of virtual networks 800, their establishment and 

configuration. This section deals also with services in the 
context of the SDI 200 and how they are added. 

• Section l. 5: "Networks Interconnection" -addresses 
the linking of the many virtual networks 800 to the 

20 transmission network 100 and determination of the appropriate 
network to handle calls. 

Section 1.6 through Section 1.10 - addresses 
requirements that span all of the application such as time, 
statistics, persistence and control. 



25 



30 



35 



!« 3 SPI ?hv«-cal NPtvnrv flog 

The topology of a physical network 805 is independent 
of a logical virtual network 800 provided over it, provided 
the capabilities of a particular node 300 are promulgated to 
a virtual network 800; e.g. a service needs to know if a 
station on a node 300 is capable of accepting a text string 
for caller name delivery. The physical network 805 of the 
SDI 200 is the knowledge of those points to which it 
interfaces in the transmission network 100. 

The SDI physical network 805 should isolate and 
uncouple vendor specific detail with respect to the 
transmission network 100 from virtual networks 800 and from 
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each other. The interface presented to all virtual networks 
300 from the physical network 805 should be consistent. 

The SDI physical network 805 can be extended as required. 
5 Referring to Figure 4, nodes of the transmission network 100 
of the current British PSTN which might be identified for 
inclusion in the SDI physical network 805 are the Digital 
Main Switching Units 400 (DMSUs), the SN Switch 405 (through 
the Service Node SLEE interface) and the SSP 110. 

10 Through suitable encapsulation, knowledge of the 

underlying transmission network 100 is not required by a 
service in order to operate. This allows services to be 
independent of aspects such as signalling protocols, call 
models, modification to the transmission network 100 and the 

15 physical access mechanisms offered by the physical network 
805. A. service can ascertain some limited physical 

attributes of a station e. g. display capabilities for caller 
name display. 

Physical elements to which the SDI 200 must interface 

20 are represented by objects in the SDI 200. It is possible to 
have any number of instances of an element type, e. g. there 
are a number of instances of SSPs representing the N actual 
SSPs declared to the SDI 200. Encapsulation of physical 
elements (objects) can be created, modified, and deleted as 

25 required to reflect the physical transmission network 100. 

An encapsulation (object) is a reflection of an actual 
physical element in software. This extends to the behaviour 
and state of an element that is required for the SDI 200 to 
inter-operate with it. E.g. for an SSP 110 this would 

30 include the cail model, the signalling protocol and the trunk 
configuration. An object is provisioned with the state 
information of the actual element. For an SSP 110, it will 
reflect the SSP-identity and all virtual trunk identities as 
configured by network operations. Each object will be 

3 5 addressable and state information is provisioned and modified 
through a provisioning interface. 
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Referring to Figure 5, to the SDI 200 the objects are 
effectively the actual entities. B y the management of 
control state information, it is possible to take an object 
500, 505 (and, as far as SDI is concerned, the actual entity) 
5 temporarily out of operation and to restore it to operation. 
Newly created objects are out of operation until explicitly 
brought into service. Additions and updates to the SDI 
Physical network 805 can be reflected in the SDI 200 by the 
deployment of a new object for the element concerned, 
10 produced by the SCE 210. 

4 - 3 - 1 -Physical Node ft =*y sica1 WqHp Addr CCC 
Network elements m the transmission network 100, 
which carry calls, generally carry calls over trunks. The 
15 elements and their trunks are addressable and are usually 
connected to other nodes on the transmission network 100 
Consequently, to the SDI 200 a physical node 300 shall be a 
trunk identity on a particular network element. Nodes of the 
SDI physical networks 805 have the attribute of being 
20 dedicated or common, a ••dedicated" physical node being 
understood to be a permanent connection carrying calls for 
a particular virtual network 800. A "common" physical node 
might carry calls for more than one virtual network 800 The 
common or dedicated attribute of a physical node is 
25 changeable. 

Nodes 305 of the SDI physical network 805 have an 
identity by which they are addressed for provisioning. SDI 
Physical nodes 305 are provisioned through a provisioning 
interface. They may be created, deleted or modified for a 
30 particular virtual encapsulation of a physical element. An 
SDI physical node 305 may exhibit a state of enabled or 
disabled, reflecting the condition of a transmission network 
noae 30Q. In the disabled state, the SDI 200 will not accept 
or place calls from or to it. 

25 
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4. 3. 1. 1 Physical Node Address 

The physical node 300 that a call originates from or 
is directed to is identified, for call processing purposes, 
by a physical node address. All physical nodes 300 have a 
5 physical node address. The physical node address and the 
physical node identity are not the same thing. 

For dedicated physical nodes of the SDI physical 
network 805, the physical node address comprises the physical 
element identity and trunk identity. 
1° Common physical nodes carry calls switched over other 

networks - there is no guarantee that two calls from the same 
station always arrive or leave on the same common physical 
node. Therefore, the physical element identity and trunk 
identity is not part of the physical network address for 
15 common physical nodes. For common physical nodes, the 
physical node address comprises, either or both, the calling 
line identity and the dialled number. The physical node 
address for a common physical node may contain anything that 
may be dialled from a Dual Tone Multi Frequency (DTMF) 
20 keypad, including * and Table 1 shows the construction of 
the physical node address. 



Physical 
Nod«5Type 


Inbound 


Outbound 


Physical 
Element 
Identity 


Virtual 

Trunk 

Identity 


Calling 

Line 

Identity 


Dialled 
Number 


Physical 
Element 
Identity 
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Dialled 
Number 


Dedicated 
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X 


Common 


X 
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y Either or both ✓ 
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X 


✓ = Will be present & meaningful: x = will not be present or pn 


esent and n 


91 meaningful. 



3 0 Table 1: Physical Node Address 



1. 3. 2 Physical Network Address 

A node 305 of the physical network 805 will, 
generally, only identify a group of possible network users. 
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It should be possible to identify and address users uniquely 
on a particular node. A physical network address uniquely 
identifies an access or termination on the physical network 
805. The physical network address comprises a physical node 
5 address and an identifying number. What the identifying 
number may be varies depending on circumstance as shown in 
Table 1. The schematic in Figure 6 shows examples of 
physical node address 600 and related physical network 
address 605. 

10 

l - 3 - 3 Operati ons on the Physical Network 
The composition of the physical network 805 is shown 
in Figure 29. 

As an encapsulation of the real world for virtual 
15 networks and services, the SDI physical network 805 must 
provide a set of operations to allow interaction with 
resources and users connected to the physical network. This 
set of operations on the physical network 805 must satisfy 
the required operations of the service interface. The 
20 operations the physical network 805 must offer are detailed 
in the following paragraphs. 

The physical network 805 manipulates the legs of a 
dialog (call) with respect to the physical elements of the 
transmission network 100 as requested. It offers a standard 
25 set of operations and localizes any specialized knowledge of 
individual transmission network elements. Physical networks 
operations enable legs to be created and deleted. If a leg 
is deleted which is the only leg within a dialog then the 
call is cleared and the dialog is ended. It is possible to 
30 specify an announcement to be played immediately prior to the'"' 
deletion of a leg to advise the end user. Legs within a 
dialog can be connected using a connect operation which will 
connect the specified legs within a dialog together. 

The playing of announcements differs across physical 
35 elements of the transmission network 100 both in terms of how 
announcements are actually played and how they are 
individually addressed. This level of detail is localized in 
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the physical network 305, which determines which element an 
announcement resides on and how it is connected to the 
specified leg. The physical network 805 accepts a play 
announcement instruction with a specified announcement 
5 identity and a leg within a dialog to connect the 
announcement to. 

It is necessary to he able to collect digits from a 
leg of a dialog. Again how the actual detail of how this is 
achieved is localized within the physical network 805. The 
10 physical network 805 accepts an instruction to collect digits 
for a specified leg within a dialog. An announcement 
identity may te provided as a prompt to be played to the 



user. 



A dialog can be ended in its entirety by using an "end 
15 dialog" operation on the physical network 805. This causes 
the dialog to be closed and the network resources that may be 
involved to be released. 

3 - 4 Physical Network Resource Al1nr rr 
20 The knowledge of the presence and capabilities of the 

physical network elements is isolated from the services. 
Consequently, a service does not request a particular element 
to perform an action, merely that the action be performed, 
e. g. play announcement. How the announcement is played 
25 requires that a decision is made based on the knowledge of 
the capabilities of the physical element currently involved, 
what other physical elements are capable of performing 
particular actions and which ones may work together. This is 
the responsibility of the physical network resource 
30 allocator. The resource allocator must ensure that the legs 
involved in a cail across elements are maintained. 

The schematic in Figure 7 represents this graphically. 
For any operations requested of the physical network 305 the 
allocator 700 shall determine the resultant operations on 
35 appropriate virtual encapsulations. 
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l - 5 Physica l Network Access 

All networks have users. Users exist in the physical 
domain. Physical network access is understood as the means 
whereby a user connected to the transmission network 100 is 
5 conveyed to the SDI physical network 605. 

There are two modes of access to the SDI physical 
network 805 - dedicated and switched access. Dedicated 
access is defined as the case where calls arrive over a trunk 
that is a dedicated connection between an encapsulated 
10 network element and customer CPE. Switched access is defined 
as the case where calls are switched through the physical 
transmission network 100 and arrive at an encapsulated 
physical element over a common trunk. 

All accesses arrive at the SDI 200 with enough 
15 information to form the physical node address. It is possible 
to determine the country and/or area of origin from the 
physical node address and the calling line identity (CLI). 

An access shall be rejected if any of the following 
are asserted: 

20 ° the vir -ual encapsulation is in a disabled state; 

• the physical node address is not known; 
° the physical node is not in an enabled state; 
A rejected access shall be connected to an 
announcement stating that access has failed, plaved in the 
25 SDI pre-selected default language. A rejected access is 
logged in the SDI Log. 

1. 3. 5. 1 Dedicar ed Acpp«?«; 

Dedicated access is possible on dedicated access lines 
30 associated with a particular physical node i. e. an SSP trunk 
The physical node exhibits the attribute of beina dedicated- 
it is by this attribute that an access from that node is 
recognised as a dedicated access type. 

35 1.2.5.2 Switched Arrocc 

Access from a PSTN or over networks of other network 
carriers is possible. Switched access calls arrive at a 
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physical node exhibiting the attribute of common and by merit 
of this are recognised as the access type "switched". Calls 
originated from the same station, using switched access, do 
not always arrive at the same physical node. 
5 A call arrives at an SDI common physical node because 

an access number is interpreted by the carrier as identifying 
the call as an IN call to be carried by the network operator 
having the SDI 200. This access number may be either the 
number dialled by the user or the calling line identity of 
10 the originating station. For switched access the physical 
node address is the access number. 

1 . 3 ." 5 . 3 Travellers Access 

A traveller is a concept only understood within a 
15 service and not to the SDI. To the SDI 200 it is merely 
switched access. A service must deduce that an access is 
"traveller" and process the call based on what a traveller 
means within that service. 

20 1. 3. 6 IP Switch 3ehavjQyr 

An Intelligent Peripheral (IP) Switch may be used to 
connect voice trunks to IP resources, e. g. the Speech 
Applications Processor (SAP). The connection of resources to 
a particular voice trunk is controlled by the SDI 200 

25 depending on what action the service is requesting. 

In the UK PSTN, an IP or SN switch may have up to 
sixteen 30 channel voice crunks to a DMSU. Calls are set up 
to the voice trunks by a C7 NUP Dialog between the DMSU and 
the service node. The switch and its resources are accessed 

30 by use of the service node SLSE API. 

1. 4 Virtual Networks 

The concept of bringing together remote hubs of a 
telecom network as one integrated network is proven in many 
2 5 large corporate voice and data networks. Linking remote 
systems requires a transmission network; either to be built 
or bought. The net effect is the appearance of a single, 
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dedicated network of users. Each dedicated virtual network 
offers particular capabilities based on what physical 
elemenrs are available within it, and, extending to the IN 
domain, what IN services are available to it. The addresses 
5 of locations within a virtual network are logical 
representations and are translations from other logical 
representations of physical addresses. This address 

translation provides the power :o separate virtual networks 
from physical networks. 
10 a virtual network can be viewed in the same way as any 

other network, the mam difference being that a virtual 
network is unaware of its physical construction. It can be 
viewed like a cloud, through which there is always a route 
from point A to point B but only the transmission network 
15 knows what it is - it may be dynamically changing. The 
connection routes are transparent (ie not known) to users. 

A virtual network has people that use it - users. 
They use some form of station on the network, e. g. a phone, 
a terminal etc. The stations are connected to a node, e.g. 
20 a private PBX, a termination point in the public telephony 
network, a channel in the cellular network etc. Nodes are 
located at sites. The virtual network in this context and in 
the context of embodiments of the present invention is the 
interconnection between these nodes. A virtual network BOO 
25 is configured to have services. A service is a particular 
communications capability, e.g. Plain Old Telephony Service 
(POTS), Voice Mail, etc. 

Each virtual network 800 has a numbering plan defining 
what it allows as directory numbers for its users and 
30 stations. The definition of a network specific numbering 
plan gives the virtual network concept the power to represent 
practically any type of network. The associations of users 
and directory numbers is maintained within a virtual network 
user directory. What part of the "world" a user is in is 
35 maintained in an atlas, where world means whatever is 
perceived by the administrator of the virtual network. Users 
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have some or all services available to them; the services a 
user has is maintained in a user profile. 

As provider of virtual networks, a carrier or network 
operator will create, enable, modify, disable and delete 
5 them. Each virtual network has a unique virtual network 
identity. Customers are able to, when allowed by the network 
operator, modify some aspects of the virtual network. 

1- 4. 1 Virtual Node & Virtual Node Addrsg^ 
i0 Al l virtual networks have nodes to which stations are 

connected. From within the virtual network a node is an end 
point e.g. a local PBX or phone jack. (As opposed to the 
physical network perspective which describes the actual trunk 
or line). _ Thus the same node is known by a physical node 
15 name and a logical virtual node name. This decouples 
knowledge, of the physical network configuration from the 
virtual network. An association must be maintained but the 
virtual network only needs to know about its own virtual 
nodes. 

20 Each virtual node in a virtual network 800 has a name. 

The virtual node name is unique within the virtual network. 
Every virtual node name has a virtual network address which 
is unique within a virtual network. Virtual nodes and their 
addresses are defined further, later in this specification. 

25 

1. 4. 1. 1 Gateway Nodes 

A particular type of a virtual node is the gateway 
node which carries calls off the virtual network 800 to 
another network (public network or virtual network). Gateway 
30 nodes behave as any other virtual node. 

1. 4. 1. 2 Sites 

A site is the place where a node is located. A site is 
35 synonymous with virtual node. No distinction is made between 
site and virtual node. 
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1 - 4 - 2 Virtual Netwnrv tH^ r.cc 

There may be one or many stations connected to a 
virtual node. It is necessary to be able to identify a 
particular station. A virtual network address uniquely 
5 iaentifies a station on the virtual network and comprises a 
virtual node address and a station number. Every station on 
the network has a virtual network address. 

1 - 4 ' 3 Virtual Network Mnn merino °1 an 
10 Every virtual network has a numbering D i an whi ~ n 

dermes valid directory numbers, dialling procedures 
(prefixes, etc. ) and the maximum length of numbers. Prefixes 
■nay be defined to indicate out of plan numbers. The 
numbering plan may be divided into any number of ranges or 
cells, up to maximum number length - 1. A numbering plan 
only describes virtual network directory numbers, not where 
they terminate or what they translate to. 

The number of entries in a numbering pl an (or sub-part 
of it) is limited by the number of digits available and the 
20 definition of what a valid directory number is. 

Numbering plans support vanity numbers, i.e. numbers 
that spell words using a commonly accepted alpha - number 
mapping. 

The numbering plan is able to encapsulate numbers from 
25 other numbering plans e.g. public numbers enabling on-net 
stations to have off -net type numbers. 

1 - 4 - 4 Director y Numhprg 

A directory number is a virtual network number. The 
identity of a user on the virtual network is his/her 
directory number (DN) . The directory number for a user may 
o. determined from the station he uses or by explicit 
identification through an authorisation code and personal 
identification number. A DN is unique within a virtual 
-5 network. Every station on a virtual network has a Directory 
Number. a DN identifies the virtual network to which it 
belongs. Directory numbers can be of variable lenoth ud to 
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the maximum length defined in the numbering plan. Directory 
Numbers may overlap, e.g. 12345 and 123456 are both legal. 
A directory number is a logical entity and is independent of 
a particular node or service on the network. 
2 The virtual network administrator is able to add, 

enable, disable and delete directory numbers. 

1-4.4.1 Associations of DNs: th e Virtual Network 

Atlas 

10 A virtual network may be global, national or local and 

an administrator may need to define the world of that virtual 
network, which may or may not be the same as established 
political or national boundaries. The location of a virtual 
network directory number in the world of that virtual network 
15 is the virtual network atlas. The atlas permits a virtual 
network administrator to define associations of DNs. 

These associations may describe any relationship e. g. 
originating geographic area, special interest groups, etc. 
There is no limit to the number of directory numbers that may 
20 be grouped together. There is no limit to the number of 
associations that may be established. Services determine 
what association a directory number belongs to. A directory 
number may only appear in one association. 

The virtual network administrator is able to create, 
25 modify and delete associations of DNs. 

l- '4.5 Virtual Network Number Directory 
The DN is defined as a logical, unique identity of a 
station on the virtual network. Generally, in telephony, a 
30 user is associated with a particular station, and when a 
user' s DN is dialled, the caller would expect that user' s 
station to "ring". (Of course, which DN is targeted and, 
consequently, which station actually rings is the 
responsibility of a service. ) 

Stations are connected to nodes and, as the earlier 
discussion on Virtual Network Address (Section 1.4.2) 
defined, are addressed by a virtual network address. It 
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will. therefore, be necessary to associate a particular 
virtual network address with a particular directory number. 

There is a directory of associations of virtual 
network addresses to DNs, i.e. a virtual network number 
5 airectory. An entry in this directory is a virtual network 
address - directory number pair. There is one of these 
directories for a virtual network. 

Where an enrry is in the directory, it is possible to 
obtain from it. one, and only one, DN for a particular 
10 virtual network address. Similarly, it is possible to 
obtain, one, and only one, virtual network address for a 
particular DM. A DN may be marked in the directory as 
enabled or disabled. 

A virtual network administrator is able to add 
IS enable, disable, modify and delete directory entries It is 
possible to view directory entries on a particular virtual 
node. 



!• 4 - 6 Users & g£a£iflng 
20 A person (or otherwise) that has legitimate access to 

a network is a user of that network. A user has a name, some 
form of identity, and other attributes that describe him A 
user uses a station to interact with the network, and would 
generally, have a normal (default) station. In line with the 
25 earlier discussion on virtual networks (Section 1.4 on Page 
20), a station is an origination or termination point 
connected to a node on the network. 

To other users, a user has an identity on the network 
- say, a directory number, and, by this identity he is 
30 recognised and other users on the network can address him 
Further, in conventional telephony, it is the station that 
has the directory number and the actual user is inferred from 
the directory number. 

A US6r may vish t0 access service from a station 

-5 other than his own (provided the service enables him to do 
this). m this case, his identity, cannot be inferred and 
must be inquired. The user needs to identify himself to the 
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network, e.g. by means of an authorisation code (e.g. a 
calling card number) and a personal identification number. 
The circumstances when identification is required are 
governed by services. 
5 Generally, a user' s station has a default service, 

e. g. a PBX line usually provides dial tone for voice service 
as opposed to, say, voice mail service. Consequently, 
therefore, it can be said that the directory number of a 
station is associated with a" user and with a particular 
10 service that the user has. Thus, a station is described by, 
and to a user is synonymous with, a directory number. 

Every user is described by a user profile containing 
information about the individual and which directory numbers 
that a user has. Each directory number identifies a service 
15 profile which is the capabilities of a particular service for 
that user. Unless a service determines otherwise, the user 
is identified from the directory number of the station. 

The virtual network administrator will add, modify and 
-deiete the profiles describing users. A user profile 
20 exhibits a state of enabled or disabled which is set by the 
virtual network administrator. 

4. 4. 7 User Profiles 

It is necessary to hold certain information about a 
25 user, within the SDI 200, that is required across many 
services. The information, considered to be non-service 
specific, that is held per user is: 

• User name, an ASCII text string of up to 50 
characters. 

30 • A user identity, an ASCII key of up to 20 

characters . 

• An authorisation code "and PIN, a digit string up to 
20 characters (including PIN). 

• Authorisation status; one of enabled, blocked or 
35 disabled. 

• Network operator Account number, a digit string up 
to <?> characters. 
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Network operator Calling Card number, a digit 
string up to <?> characters. 

• Customer Type Identifier, a single digit identifier 
"B M (business) or " P" (personal). 

5 0 User state, a single digit identifier describing a 

state of enabled or disabled. 

A Directory number keyed list of schedules of 

servi ces . 

User profiles are addressable by the user identity/ 
10 authorisation code or by one of the directory numbers that a 
user possesses. User profiles are persistent. Each DN that 
a user has within his profile has a schedule. The DN 
schedule identifies a particular service profile for a 
particular time of day. Referring to Figure 9, one service 
15 profile 900 is always identified. 

The service profile description associated with a DN 
contains: 

A time expression detailing the time that this 
service profile is active. 

20 ° A defa "lt service profile indicator, marking a 

profile as the default for this DN. 

o A service profile identifier referencing the actual 
service profile. 

• A service identifier indicating the name of the 
25 service the service profile describes. 

The service profile referenced does not have to be 
exclusive to this DN and may be used by any number of other 
DNs, provided the service itself is shareable (this is the 
decision of those provisioning. The SDI 200 does not provide 
30 any form of logic checking on the sharing of service profiles 
900). 

Once a user profile exists it is not possible to 
modify the user id, ail other components may be changed. 

The virtual network administrator is able to create 
35 and delete user profiles. User profiles may only be deleted 
when the directory number list is empty. User profiles are 
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modifiable by a virtual network administrator. A user may 
modify the authorisation code and PIN. 

i. 4. 8 User Directory 
= Every user on a virtual network has a user profile 

within that virtual network. User profiles are held within 
a user directory. It is possible to locate one, and only one, 
user profile in the user directory using the following 
individual keys: 
10 • User identity. 

• Authorisation code. 

• Directory number. 

Thus, for a given DN it is possible to obtain, from a 
user profile, a service name and a service profile identifier 
15 (and, indeed, any other information in a user profile). 

User profiles may be added to, replaced within and 
deleted from the user directory by the virtual network 
administrator. 

20 1-4.9 Virtual Network gervjc^g 

This section briefly addresses two areas for the sake 
of clarity and completeness. Firstly, it relates concepts 
and processes of an IN Architecture and a service creation 
process. Secondly, and more pertinently, the section details 

25 the requirements describing how services are to be deployed 
within the SDI 200. This includes the delivery of a service 
to the Intelligent Network Element and the activation of a 
service within the domain of a virtual network. 

30 It might be noted that a service creation architecture 
suitable for use with the SDI is described in the present 
applicant' s co-pending European patent application number 
94302848.0, filed on 21 April 1994, the subject matter 
disclosed therein being incorporated herein by reference. 

35 Other service creation architectures or environments could 
however be substituted. 
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It might also be noted that an IN architecture is not 
essential to support embodiments of the present invention. 
It is, though, important to design in suitable interfaces for 
the SDI 200. 

5 A service, within the context of the intelligent 

network element, is a specific logical „ t Qf 
telecommunication capabilities that have been packaged and 
made available to be deployed on a virtual network e g 
voice services, voice mail, fax store & forward etc A 
10 service is accessed by a user through his virtual network. 

Services are separately developed entities to which 
the SDI 200 interfaces. A virtual network 800 supports more 
than one service. 

The IN Architecture and various SCE requirements rely 
IS on reusable software components which are not specific to any 
one service and which are used as the parts from which 
services are assembled. Referring to the above-mentioned co- 
pending application, these components have been termed 
Generic Service Components (GSCs). GSCs are developed 
20 tested and released by engineers using an SCE tool-set and 
test harnesses. GSCs targeted for deployment at the IN 
Element, are conveyed to the IN Element and deoosited in a 
Feature Library. 

Services are designed and constructed, to a specific 
25 set of requirements, by service designers using different SCE 
tools and processes. Service designers can use GSCs made 
available to them by the SCE as above. Once constructed and 
testea to be network worthy, the service must be deoloyed in 
the appropriate elements in the IN Architecture 

30 

1- 4. 9. 1 SDI Service Enoi nr. 

Services, to interwork with SDI. are developed to 
operate within the confines of an SDI service engine 825 
The SDI service engine 825 provides a bounded environment and 
35 denned interface within which services run. The interface 
enables services to avail of resources outside that boundary, 
e- g. the virtual network directories, the physical network. 
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physical interfaces to other operational support systems etc. 
The service engine 825 performs ali the necessary correlation 
of the GSCs in the feature library with those used in a 
service. 

5 The service engine 825 perforins service discrimination 

for a call. Once the target service is identified the 
service engine executes the appropriate service. The service 
engine provides to services a mechanism for maintaining call 
context. 

10 A novel aspect of embodiments of the present invention 

is the use of a software " blackboard" technique in the SDI 
service engine 825 and is described later in more detail. 

1. 4. 9, 2 Service Dictionary 

15 A virtual network has a specific set of services. 

These services are added by the BT IN administrator. The 
collection of services available to a virtual network is 
localized in a Virtual Network Service Dictionary. For every 
Service that a virtual network has, there is a corresponding 

20 entry in its service dictionary. The entry in the service 
dictionary fully describes that service. An entry in the 
service dictionary holds: 

♦ the distribution media version of the service - the 
service package; 

25 • the installed service; 

• the directory of all that service' s profiles 
describing how the service operates. 

1. 4. 9. 3 Service Packaoe 

30 Services are delivered to the SDI 200 in a 

distribution media format which is termed the service 
package. The form the media will take will not have any 
dependency on the contents of a service package. The service 
package provides all that is required to install a service 

3 5 into a virtual network 800 for use by the SDI service engine 
825. A service package does not contain executable code. A 
service package references existing executable components in 
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the SDI feature library. The service package defines the 
order of execution of those referenced features. The service 
package defines the profile description of the service. The 
service package is the defined service interface between the 
5 SDI 200 and the SCE 210. 

1-4.9.4 SDI ServicP 

A service is considered to be a unique entity which 
only has meaning within the context of a particular virtual 

10 network 800. Therefore a virtual network 800 must exist 
before a service can be deployed within the SDI 200. 
Irrespective of the similarity of two services, either in 
construction or behaviour, on two virtual networks, they are 
two distinct, and to all intents and purposes, different 

15 services. 

An SDI service is an executable application that can 
process calls. The SDI service is constructed from the 
service package to form an executable application. The 
service engine 825 performs the linking of all the referenced 
20 executable components which the service package states 
comprise the service. The installed service is controllable 
through a management interface which shall make it possible 
to: 

• query or set the control state of a service which 
25 is one of enabled or disabled; 

» query or set the state of a feature; 

• iterate over the features in a service, i.e. move 
to the next feature without knowing its name; 

• query and sec the service name; 

30 ° query and set th e Billing identity for a service; 

• query and set the ordering of feature execution 
within a service; 

• query and set the resources of a service, e.g. the 
maximum number of permirted simultaneous calls. 
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1.4.9.5 Service Prgfile Directly 

Every service available to a user on a virtual network 
800 is described by a service profile. Service profiles are 
stored in a service directory. It is possible to locate one, 
5 and only one, service profile in the service directory using 
the following individual keys: 

• Service profile identify 

A service profile may be added to, replaced within or 
deleted from the service directory. 

10 

1. 4. 9. 6 Service Profiles 

A service profile defines the particular behaviour of 
a service and is the required description of that service as 
configured _for a user, or group of users. A service profile 

15 is persistent. The contents of a profile are specified by 
service designers and are not understood by SDI. While the 
contents are not understood there are several things that SDI 
requires to read from every service profile, namely, the 
"service name and the state of the service profile i. e. 

20 enabled or disabled. Service profiles are provisioned over 
the provisioning interface, service designers stipulate what 
users' modification rights exist. A service profile is 
addressable by a unique service profile identity. 



25 1.4.9.7 Addinc A Service to a Virt ual Network 

A service can be added to a virtual network, provided 

the service exists in a library on the network element; a 

service may be deleted from a virtual network. All services 

have a control state of enabled or disabled which a virtual 
30 network can read; this state is modifiable by the BT 

administrator (or maybe, by" the service itself). 

Referring to Figure 4 7, the steps involved in adding 

a service to a virtual network 800 from the SCE 210 can be 

simply set out as: 
35 i) creating a service profile and deploying it at the 

virtual network 800 (STEP 1); and 
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ii) updating the user profile with a VDN and service 
profile reference and deploying the updated user profile to 
the virtual network 800 (STEP 2). 

In more detail, before a service becomes available to 
5 any user on the virtual network 800, the following must 



occur: 

o 



the media version of the service entered into 
service dictionary; 

the service must be installed into the virtual 

10 network. 

0 the service must be given to a particular user. 

The virtual network 800 has an operation to add a 
service. This operation expects a service package. The 
operation of adding a service causes an entry to be created 
15 in the service dictionary and the service package to be 
placed there. 

The virtual network 800 has an operation to install a 
service within a service dictionary. This operation fails if 
either the service package is not present or if the installed 
20 version of the service is newer than the service package. 
The latter condition may be explicitly over-ridden. The 
action of installing a service does not affect any profiles 
for that service. Any necessary profile migration is 
performed by a separate means. Installing a service on the 
25 virtual network strips the necessary information out of the 
service package that is required by the service engine i.e. 
the feature (component) references; 
the feature order of execution; 

specific resource information (e.g. max 
30 simultaneous calls); 

the billing identity and name of the service 
the service control state (i.e. enabled, disabled 



0 

o 

0 



0 
0 

etc. ) . 



The install operation causes the service engine 825 to 
35 perform the necessary actions to retrieve referenced 
components from the feature library and ready them for 
execution. If the service engine is unable to make a service 
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ready for execution the operation of installing the service 
in the virtual network 800 is deemed to have failed. 

The virtual network install service operation also 
causes the allocation of the necessary resources within the 
5 SDI 200 in accordance with the resource specification in the 
service package. 

Service profiles for the service are constructed and 
edited at the SCS 210 as defined for the particular service 
and delivered to the Service Profile Directory through the 
10 provisioning interface. 

1. 4. 10 Virtual Network Se rvice Access 
From the discussion on virtual nodes and virtual 
network address (Section 1.4.1 and Section 1.4.2) it follows 
15 that a virtual network 600 is identified by the time these 
are deduced. (The discussion on what is required to identify 
a virtual network 800 is covered in Section 1.5, "Networks 
Interconnection" below. ) 

A virtual network can be viewed as a community of 
20 users. A virtual node address does little more than to 
pinpoint the community. A virtual network address uniquely 
identifies an individual within the community. 

The virtual network has the responsibility to identify 
a particular service. Services understand DNs ; services have 
25 no concept of virtual network address. 

Referring to Figure 11, the access information that a 
virtual network 800 requires, for an origination from the 
physical network, is the virtual network address. From that, 
the virtual network number directory (Section 1.4.5) is 
30 capable of deducing a DN. It has been previously stated that 
a virtual network, virtual node address, a virtual network 
address and a directory number all exhibit a state of enabled 
or disabled. If any of these states should be disabled for 
a given network address then access is denied. When access 
35 is denied the caller is connected to an appropriate 
announcement and an entry is made in the SDI log. 
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The DN is a key to a service name and a service 
profile (see the earlier discussion on user profiles; Section 
L4 - 7) - The service profile gives the service the 

information required to handle this call for this user. 

l ' 4 ' 11 Virtya] Not-work Toll TLzteX £fllls££fl£ 
Services require to send charging information, in the 
form of call detail records, to the appropriate billing 
systems. A call detail record may be one or a number of toll 
10 tickets produced by the service. The service designers 
define what a call detail record is. 

A service places toll tickets with the Virtual Network 
Toll Ticket Collector. The contents of a toll ticket is 
defined by the service designer and is not understood by the 
15 SDI 200, however, it is possible for the SDI 200 to read the 
following about a toll ticket: 

• the dialog identity producing the toll ticket; 

• the toll ticket sequence number within the dialog; 

• the service name producing the toll ticket; 

2 ° • the type of toll ticket being one of: {Solo,' First, 

Intermediate, Final} 

When a service is added to a virtual network 800 it is 
able to (and, indeed, must in order to send toll tickets); 

register a service name with the toll ticket 

25 collector; 

* register one of a possible set of toll ticket 
handling instructions. 

The toll ticket handling instructions tell the 
collector what to do with toll zickets produced by a service 
30 and is one of: 

automatically forward all toll tickets upon 

receipt; 

• automatically forward complete toll ticket sets. 
s When polled, forward all toll tickets; 

when polled, forward complete toll ticket sets 
complete toll ticket set is either a solo toll 
txcKet or a sequence for which a final toll ticket is 



35 • 

A 
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present. The virtual network toll ticket collector 

automatically purges toll tickets once delivered to the SDI 
billing interface. 

5 1. 5 Networks Interconnection 

Referring to Figure 12, the physical network 805 
describes the entities in the physical network. The virtual 
network 800 describes the nodes in each virtual network. 
There is a network interconnect 810 maintaining the 

10 connectivity information of how each virtual network 800 
relates to the physical and other virtual networks. The 
network interconnect 810 handles originations and dialogs 
with the physical network identifying virtual networks; and 
liaises with the physical network 805 on behalf of virtual 

15 networks 800. 

1. 5. 1 Vjr^aj, Npde 

Referring to Figure 3, a physical node in the physical 
network 805 has users of a virtual network 800 connected to 
it. That node must be identified in some manner to the 
virtual network. There is a logical' means of referring to 
physical nodes, thereby decoupling the physical network 805 
and leaving the physical network operator free to manipulate 
node assignments. 

The virtual network 800 has virtual nodes 310. These 
are the only nodes a virtual network 800 is cognizant of. 
Users are connected to a virtual node 310 on the virtual 
network 800. Each virtual node 310 has a name and a virtual 
node address. 

Virtual nodes 310 have originating and terminating 
attributes, which may be undefined. Undefined originating or 
terminating attributes signify that a node is incapable of 
carrying originating or terminating calls respectively. This 
enables the virtual network 800 to distinguish between 
different origination and termination behaviour for a user of 
the virtual network 800. 



20 



25 



30 



35 
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Virtual nodes can be created or deleted only by the 
network provider or operator for any virtual network 800. A 
virtual node 310 can exhibit a state of enabled or disabled. 
The network administrator of the network operator is able to 
5 modify the state of a node. All new nodes are created with 
a state of disabled until explicitly enabled. A virtual 
network administrator is able to view virtual node 
information but unable to modify it. 



10 



1 - 5 - 1- 1 Virtual Node Arirlyocc 

Every virtual node 310 has and is referred to by a 
virtual node address. A virtual node address indicates the 
virtual network identity and the node name, or number, within 
that network. 



15 



20 



l - 5 - 2 Virtual Network Dj § cri mi naH r>r> 

All calls arrive at some physical node 305 in the 
Physical network 805. It is necessary to determine which 
virtual network 800 should handle the call. 

Virtual network discrimination is achieved through the 
identification of the virtual node 310 that is associated 
with a particular physical node 305. The virtual node 
address indicates the virtual network identity. 

A call is handled by a virtual network 800 if and only 
25 if all the following are asserted: 

• the physical node address is one that is known; 

• the physical node address is associated with a 
virtual node; 

• a valid virtual network can be deduced; 
30 * the virtual network is active. 

1 ' 5 ' 3 p *VgigaJ Node to vernal Nojjg Acc r r ^ r 
The network interconnect 810 maintains the 
relationships between physical nodes 305 and virtual nodes 
35 3 10. It is possible to associate a maximum of two physical 
network nodes 305 with one virtual network node 310 - one 



WO 95/23483 



PCT/GB95/0042I 



- 43 - 

being the originating attribute and one being the terminating 
node. 

This relationship is provisioned by the administrator 
of the network operator. 

5 

1. 5. 4 Access Numbers for Switched Access 
An access number is a public number that is known to 
the network operator and customers as a VN access number. 
The access number can be either the number called (the 
10 dialled number) or the number called from (the calling line 
identity). An access number is to the SDI 200 a physical 
network address. An access number is treated just like a 
physical node 305 and associated with virtual nodes 310 as 
previously described. 

15 

1. 6_ Time Requirements 

The SDI 200 maintains a network time which is 
available to all components and services. The network time 
is that time that is chosen for the network to operate on and 
20 is not necessarily the local time. By use of the appropriate 
delta value from network time, services and components are 
able to deduce a local time - if required. The SDI time has 
a granularity of one millisecond. 

25 l. 7 Persistence Model 

The SDI 200 provides a persistence model for objects 
of virtual networks 800, the physical network 805, network 
interconnect objects and service objects. The persistence 
model shall manage the storage of all persistent objects. 

30 All managed persistent objects shall be addressed in a 
Managed Information Base (MI 3) (not shown). The persistent 
store is capable of supporting real-time service 
applications. 

It will be understood from object oriented 
35 environments that managed objects are objects in which data 
is encapsulated by management process software. 
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The persistence model provides for local backup. 
Services are nor mvasively affected by backups and operate 
normally during a backup. Backups may be scheduled in 
advance. Backups can be specified to the following levels 
5 of granularity: 
o Full 

0 Physical Network 
° Network Interconnect 
° Virtual Network(s) 
10 ° Feature Library 

0 User Profiles of Virtual Network(s) 

Service Profiles of Serviced ) of Virtual 

Network (s ) 

0 Number Directory of Virtual Network(s) 
15 ° Service Package (s) of Virtual Networks ) 

Restoration of backed up information will cause a 
change in behaviour of the items being restored to reflect 
their state at the time it was backed up - restoration of 
data is an intrusive activity. 

20 

The requirements for statistics collection and reporting will 
vary according to e.g. network operator and are not detailed 
25 here. 

Components maintain their own statistics. Components 
emit statistical information when requested. 

Services would be expected to have specific 
requirements for statistics collection. 

30 

1. 9 Loc 

The SDI 200 has a log utility whic h all other 
components can use to log activity and even, messages. The 
log utility interfaces wirh the UNIX (compucer harliware 
3- operating system developed by AT&T) file system. 

Log messages are of variable length. Loo files are in 
ASCII format. 
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It is possible to determine the following for each log 
mes s age: 

• Log Message Identify - a unique sequence identity. 

• Time stamp - a time expression recording the time 
5 of the event. 

• Message Type Name - one of {Exception, Activity} 

• Logging Component Name - the name of the component 
producing the log event. 

• Customer Context - as much information that is 
10 known about the customer when the iog event is generated e. g. 

virtual network identity, directory number, user identity, 
service profile identity etc. 

• ASCII readable Text - The actual message. 

Log files roll over at the end of a specified log 
15- period or when the log reaches a specified size. Log files 
are given a specified amount of disk resource within which to 
exist so that the operation of the' node is not stopped by 
.proliferous log messages. When log resource reaches a 
threshold the oldest logs are automatically purged ensuring 
20 new log messages are not lost. 

All components are able to place messages on the log. 
It is possible to retrieve log messages. 

It is possible to produce reports of logs and 
establish queries for the reports through a human/machine 
25 interface (HMI) screen. Log report criteria can be 

constructed from compounded conditions of: 

• Time period 

• Message types 

• Component name 

30 • Customer (virtual network) 

The management of logs is provided i. e. 

• It is possible to force close and restart of a 
named log. 

• It is possible to delete an unopen log. 

35 • It is possible to specify a retention period. 

• It is possible to specify the roll -over period 

• It is possible to specify the roll-over size. 
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• It is possible to specify the resource limit for 

logs . 

• It is possible to set a percentage threshold for. 

The log informs network management 820 of creation, 
suspension, closing, deletion and roll-over of loos. Network 
management 820 is informed when a threshold resource limit is 
reached. 



10 



l - 10 Process ManaaemPnt Cnnt;^! 
The components of the SDI 200, and services that run 
under its auspices, are all contained within a finite set of 
manageable processes on the target platform. These processes 
are managed in two ways, i.e. invasively by an operator or 
15 automatically by heartbeats. 

Every managed process is required to resoond to a 
heartbeat. Failure to respond to a heart-beat for a 
configurable, consecutive number of times causes an automatic 
management action to be executed. The action can be 
20 configured and is one of: 

• restart 

• kill 

• suspend 

• (other actions?) 

25 invasive operations by an operator are possible. Each 
managed process accepts the following stimuli for the 
purposes of process control: 

suspend (Go Out of Service) 
resume (Come In Service) 



30 



• reinitialise 

2- SYSTEM TWTFP^rrc 



„ . " iS Ci6ar that the SDI 200 has to provide or 

3. interface with a wide range of network systems, such as 
Billing, these being provided overall by the intelligent 
network (IN). Referring to Figure 10, the SDI has various 



WO 95/23483 



PCT/GB95/U0421 



sets of interfaces to support the deployment, operation and 
management of IN services. The system interfaces can be 
categorised as: Transport Network Interfaces 1010; Service 
Creation Architecture Interfaces 1000; Operations & 
5 Management Network Interfaces 1030; and Human Machine 
Interfaces 1020. 

The interfaces to SDI will comprise those required to 
support the IN services to be deployed. 

The transport network interfaces are discussed here as 
10 an example only. The interfaces to the physical transport 
network will be constrained by circumstance as well as by the 
design philosophy and strategy of SDI. Overall: 

i) "the SDI provides an abstraction of the physical 
transport network so that virtual networks and services can 

15 be created without requiring cognisance of the physical 
topology of the transport network; 

ii ) the SDI is an extensible and evolvable product; 
iii ) the SDI in the present embodiment of the 

"invention accesses the transport network resources through a 
2 0 service node service logic execution environment ; 

iv) it is the interfaces to the transport network 
necessary to deliver the IN services actually to be deployed 
which are required. 

The requirement that the Service Node SLEE is used 
25 forces these interfaces to be expressed in terms of SLEE API 
commands. This prevents the fulfilment of total virtual 
encapsulation within the SDI. In general, the SLEE is used 
to provide the physical interface to the devices. Thus, for 
example, although a DMSU network (switch) interface is 
30 physically C7 NUP to SDI the DMSU appears as a device that is 
driven by a subset of the applications programming interface 
offered by the SLEE. It is in terms of this API that the 
transport network interfaces are specified for the SDI on the 
SN platform. 
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2. 1 DMSU T nt - erfaet? 

The DMSU !10 is a Tandem switch in the UK PSTN 100. 
The DMSU no wiii pass IN calls co the SN 125 for processing. 
This is the only interface to the PSTN 100 that is provided. 

2- 2 SAP IntPr^rp 

The Speech Applications Processor 1035 i s an 
Intelligent Peripheral (IP) device connected to the service 
node 135 and hosts a set of interactive speech applications, 
10 used to solicit information from a telephone caller. The 
SDI -SAP interface will be realised through the use of a 
suitable Applications Programming Interface. 

The remaining interfaces are each constrained by the 
15 particular proprietary equipment to which they are connected 
and are nor further detailed herein. Other proprietary 
situations would require different interfaces. 



3. SDI MODFT. 



20 



Referring to Figure 13, the context of the SDI 200, in 
relation to a transmission network and associated systems, 
and major components of the SDI are shown. The SDI 200 uses 
the SN SLEE to interact with all transport network devices 
25 The management network 820 uses the SLEE to interact with 
appropriate external network management systems. 

Service creation interfaces are encapsulated within 
the management network sub-system 820. 

As mentioned above, the SDI 200 virtually encapsulates 
30 the transport network 100 in a physical network system of 
interacting objects. The physical network 805 is a 

representation of network capability and hides network 
topology and protocols. The SDI physical network 80S 
presents a consistent network operations interface to the 
35 rest of the SDI 200 for interaction with the transmission 
network 100. 
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The Network Interconnect component 810 of the SDI 200 
maintains the connectivity information between physical and 
virtual networks 805, 800 and provides for the 
interconnection between all networks. The Network 

3 Interconnect performs network discrimination. It presents 
the same consistent network operations interface. 

IN services run in the Service Engine Governor sub- 
system 825. For the sake of performance, service execution 
is grouped into one sub-system rather than provide a service 
10 engine within each virtual network. The service engine 
governor sub-system 825 performs service discrimination and 
service execution. One could take the logical view that the 
service engine of each virtual network is centralized into 
one object, for the sake of efficiency in a real time 
15 environment. The service engine governor subsystem 825 has 
libraries _of service application features, provisioned by the 
SCE, that are referred to by Marketable Service Features 
within a Service Package. 

20 3. 2 The SDI Transaction Protocol 

As described, the SDI 200 can be viewed as a set of 
networks and resources. Networks and resources within a 
network communicate with each other using defined protocols 
and message sets. The SDI 200 has a defined protocol for 
25 communication between resources and networks: the transaction 
protocol. In the context of the SDI 200, a transaction 
protocol resource is any element which is capable of being 
involved in a communication using the SDI transaction 
protocol. The SDI transaction protocol defines how resources 
30 talk to each other and what they say. 

Resources converse using the transaction protocol. 
The conversation can include any number of resources but that 
conversation :nust be focused relative to a particular 
transaction, where a transaction is a discourse about one 
35 particular subject e.g. an IN call. The transaction protocol 
is transaction based, similar to the known Signalling System 
7 mechanism, where transactions can be opened using a begin, 
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continued using a continue operation and closed using an end 
operation. 

Referring ;o Figure 15, the complete conversation that 
resources 1500 have is a transaction. Each contribution to 
5 a transaction is termed a dialog. In "well-behaved" human 
communication a person must first obtain the "ear" of his 
audience and then deliver his message. 

In the SDI transaction protocol the attention of the 
target resource is gained by the use of begin, end and 
10 continue methods. The message is delivered to the listener 
is a dialog. 

Referring to Figure 28, the SDI Transaction Protocol 
2800 is the abstract base class for resources 1500. It 
provides for the behaviour of routing dialogs between 
15 resources 1500, and queuing dialogs until the resource is 
able to handle them. 

A transaction protocol resource 1500 can have a state 
of value-add mode. This enables it to realize that, although 
the dialog is not intended for this resource, it may have 
20 some value to add to it so as to make it meaningful to the 
target resource. A resource in value add mode scans the 
dralog- s parameters and adds any missing information to which 
the resource has access. Resources have status information 
and may be enabled or disabled. 
25 The SDI Transaction Protocol 2800 provides for the 

handling of three different dialog transaction types: begin 
continue and end. A begin is not possible if there is an 
entry in the open dialog list with the same transaction 
identifier. Continue and end are not accepted if the 
30 transaction has r.ot been opened. 

3. 2. 1 Dialog 

Referring to Figure 16, a dialog 1600 is a commuting 
object that allows the exchange of information between two 
35 resources involved in a transaction. A dialog identifies the 
transaction to which it relates by the transaction protocol 
identity 1605. It contains the resource names 1610 that 
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correspond to the sender and addressee of the dialog. Also 
it has one or more operations 1615 to be carried out by the 
destination resource. 

Operations 1615 can be added and removed to a dialog 
5 1600. There is no way to specify the order of placement of 
operations within a dialog. Operations 1615 are returned 
from a dialog in first -in- first -out order. The transaction 
Protocol does not enforce any order of processing of 
operations on a resource. 

10 

3. 2. 1. 1 Routing Dialogs 

Resources 1500 are grouped into resource areas. Each 
resource area has an area router, which is the only resource 
that knows, about resources in other areas. The resource 
15 naming convention is used to group resources and inherent in 
this convention is the area router for a particular resource 
group. 

Dialogs 1600 are routed based on the value of 
"destination resource and originating resource. The 
20 originating resource most recently sent the dialog. Each 
resource only knows about the resources it has connected to 
it, and their area router. 

This information is stored in a routing table. 
Resources use the routing table to pass the dialog through 
25 the system. If the destination is in the routing table it 
proceeds to the destination. Otherwise, if there are two 
entries in the routing table it proceeds to the one not equal 
to the originating resource. If there are more than two 
entries in the routing table it sends the dialog to its area 
30 router. If the current resource is the area router, it sends 
the dialog to the network interconnect. 

3. 2. 2 Operations 

Referring to Figure 17, operations 1615 are the 
35 mechanism by which resources 1500 have other resources 
perform some action. An operation 1615 can be to initiate 
some action or it can be the response to some previous 
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operation. The operations that are valid for a particular 
resource are dependent on that resource. A resource rejects 
operations it does not understand. 

Every operation 1615 has a unique name 1700 
operations can have one or more parameters 1705 associated 
with them. 

There are a number of categories of operations 1615 
that are identified as required: 

• Connection Operations - those that are required to 
10 manxp u l ate the parties involved in a particular IN call. 

• Announcement Operations - those operations to 
effect the connection of network resident announcements to a 
Party in a call. 

15 colleJ C ; UeCtion Operations - those requiring the 
15 collection of information from a party. 

3 " 3 .Transport Metwm-V ^ trarti n n 

Referring to Figure 29, the 301 Transport Network 805 
is a virtual encapsulation in software hiding the detail of 

:::::: ~- — - -u— P ^:: 

access mechanisms and changes to the transmission network 

Protocol r SP ° rt NetW ° rk AbS " aCti - 8 °5 is a Transaction 
Protocol Resource 1500 communicat:ing inter 

externally using dialogs 1600. 

(Note the terminology of the components of the SDI 
Physical network 805 shown in Figure 29 are either known from 
.his specification or can be identified by reference to 
terminology of the current UK PSTN. For instance, " RIDE" is 

30 I <- SyS K tem SUPplying ««**.d ^formation from 

30 distributed information environment. ) 

reaue S t Th H\ PhyS1Cal '° S ° PM » tM °" ele -"« ■■ 

requested by dialog operations and directs events from the 

transmission network 100. it localizes any specialized 

35 2 Z ^ ir - diVidUal -twork elements. The SDI 

35 200 ensures the graceful release of resources when a call is 
ci Bsrscl, 
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Some limited physical attributes of a station e. g. 
display capabilities for caller name display are propagated. 
The physical elements to which SDI must interface are 
virtually encapsulated in software. It is possible to have 
5 any number of instances of that element type, e. g. there 
could be N instances of DMSU representing the N actual DMSUs 
declared to SDI. Virtual encapsulations of physical elements 
can be created, modified and deleted as required to reflect 
the physical transport network 100. 

10 A virtual encapsulation is provisionable with the 

state information of the actual element, e. g. for a Speech 
Applications Processor (SAP) it reflects the SAP-identity and 
all application identities and parameters as configured by 
network operations. Each virtual encapsulation is 

15 addressable and state information is provisionable and 
modifiable- through the provisioning interface. 

3. 3. 1 View of Parties in a Call 

20 A call is a communication of some sort. A 

communication is considered only to be meaningful when more 
than one party is involved. All parties in a call need not 
be human e. g. a tone generator, an announcement player etc. 
Each party in a call is connected to some physical entity, 

25 this connection is termed a Leg of a call. 

Referring to Figure 18, a Leg 1800 represents a party 
in a call, both in terms of the physical and virtual network. 
The leg contains the physical network address 1805, virtual 
network address 1815, virtual directory number 18 10 and 

30 station attributes 1820. 

All of this information may not be present when a leg 
1800 becomes known to the SDI 200; e.g. inbound legs will 
only have transport network information present. Leg 
information can be enriched by a number of resources within 

35 the SDI 200. Discussed here is a leg 1800 as a commuting 
object that is understood by Network Interconnect 810 and 
Service Engine Governor 825. 
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3. 3. 2. 3 Collect Dicits Operations 

A service can request the collection of digits from 
the originating leg of a dialog. For a collect digits 
request, the service engine governor 825 sends a "dialog 
5 continue message" to the network interconnect 810. The 
dialog contains the collect digits operation with the 
following parameters: 1) originating leg; 2) number of digits 
to collect; 3) interdigit timeout; 4) total timeout. The NI 
8 10 passes the dialog to the physical network. This dialog 
10 goes to the resource allocator 2900. 

The resource allocator 2900 uses its resource 
capabilities table to determine whether the originating 
resource 1500 identified in the originating leg of this 
dialog can collect digits. If the originating resource can 
15 collect digits, the resource allocator 2900 sends a "dialog 
continue message" to the identified resource containing the 
collect digits operation and the parameters listed above. 

The originating resource must then translate the 
"collect digits operation request to physical hardware 
20 commands which instruct the resource to collect the digits. 

3. 3. 3 Access from the Transport Network 
All parties on a call use a station connected to a 
physical node. To the SDI 200 a physical node is a 
25 particular trunk on a particular device in the transport 
network. As, mentioned above, there are two modes of access 
to the SDI physical network 805 - dedicated and switched. 

3. 3. 3. 1 Physical Node 
30 Dedicated access is where calls arrive on a dedicated 

node. Switched access is where cails are switched and arrive 
on a common node. Each physical node is provisionable as 
dedicated or common. 

Referring to Figure 30, a SDI physical node 305 is a 
25 provisionable abstraction of a physical network element and 
a trunk that uniquely identifies a group of stations in the 
transmission network 100. It contains provisionable access 
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in the dialog to ensure the correct resource is used should 
a collect digits be the next operation. 

3. 3. 5 Use of Service Node SLEE 
5 Referring to Figure 20, the network operator SN SLEE 

2000 expects IN applications executing on it to 

• have knowledge of the transport network topology; 

• go to the SLEE to look for new call events; 

• only process one call at a time within one 
10 application; 

• suspend a call before looking for another call 

event; 

• use a specified API to interact with the network 
and management elemenis. 

15 These points do not support the general principles of 

the SDI in which the services have no knowledge of the 
underlying network topology, are multi -threaded to handle 
.multiple calls simultaneously and expect to receive 
asynchronous unsolicited events from the network. 

20 In order to use the SLEE 2000 to feed the SDI call 

events, an SDI application will run on the SLEE. This 
application will solicit events from the SLEE and push 
commands back out to the transport network. There are two 
halves to the SLEE interface; an event gateway 2005 which is 

25 a SLEE application with the API bound in, capable of handling 
one call at a time, and a conversation resource dispatcher 
2010 which will dispatch events from the gateway 2005 into 
the SDI 200 and from the SDI 200 back to the gateway 2005. 

The SleeEventGateway 2005 is the main interface 

30 between the SDI 200 and the SLEE 2000. It retrieves call 
events from the SLEE call event queue. 

Call events may be inbound events from the transport 
network or outbound events from the dispatcher. The events 
are either passed them to the SDI for further processing or 

35 SLEE API calls are made to perform operations requested by 
the SDI on the physical network IP resources. It uses the 
call event message group and event type to determine what 
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Network resource interface objects. It also receives SDI 
Dialog messages from the SDI Physical Network resource 
interface objects requesting operations to be performed on 
the SLEE IP resources. It converts these requests into the 
5 SLEE call events, sends them to the SLZE CRH (Conversation 
Resource Handier). The SLEE CRH places these call events 
back to the SLEE call event queue. 

The Dispatcher 2010 is registered as a SLEE 
Conversation Resource m order to use the SLEE CRH to 
10 communicate with the SleeEventGateway 2005. The 
SleeEventGateway 2005 sends the Dispatcher the call events 
retrieved from the call event queue. The Dispatcher then 
dispatches the call events to the SDI Physical Network 
resource interface objects, 
15 An SDI Dialog object is used as a commuting object 

that conveys state and operational instructions between 
resources involved in a transaction. The Dispatcher uses the 
dialog object to communicate with physical network resource 
"interface objects, e.g. a DMSU, the SAP, and RIDE. 
20 Depending on the message group and state of a call 

event, the dispatcher 2010 sends a dialog message to the 
appropriate SDI Physical Network resource interface objects. 

3. 3. 5. 3 New Incoming Calls 

25 The call event retrieved may be of call event message 

group API_CM_EVENT with an Incoming Call event, indicating 
that this is a new incoming call. The Dispatcher 2010 
creates a Dialog object. The Dialog object contains a Dialog 
object ID 1605 ( Trans actionPr otoc oil D ) , which uniquely 

30 identifies this call event in the context of the SDI . The 
Transaction Dialog ID 1605 is associated with the SLEE dialog 
ID in the call event, and the association is stored in the 
Dialog Dictionary. The Dispatcher 2010 may, for example, 
create a Dialog object, and send the DMSU a begin( Dialog) 

35 message. 
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3. 3. 6 PSTN Elements 

All interfaces to the PSTN are made via one Digital 
Mam Switch Unit 110. 

5 3. 3. 6. 1 Digital Main Switching Unit 

Referring to Figure 21, DMSU 2100 encapsulates the 
state of a DMSU switch. A DMSU has a SwitchID 2105 and 
Trunks 2110. A DMSU can be enabled and disabled. The 
Administrator of the network operator provisions the DMSU 

10 2100 with Trunks. A DMSU translates between DMSU Trunks 2110 
and transmission network nodes 300. For an incoming leg # the 
DMSU consults the physical node directory to find the 
physical node 300 associated with the incoming trunk. For an 
outgoing lag, the DMSU 2100 consults the physical node 

15 directory with the physical node to determine the DMSU trunk. 

3- 3. 7 Announcements, Speech Applications & Assnn'^oH 

Devices 

An announcement is a message that is available to be 
20 relayed to a user. Announcements either inform of progress 
and require no response or are prompts for collection of 
information. All announcements that are available are in the 
Announcement Catalog. 

There are two levels of announcement addressing. One 
25 is the virtual announcement identifier which refers to a 
particular meaning e.g. "Your call cannot be completed at 
this time". The other is address the actual physical 

announcement recording of that meaning in a particular 
language. 

30 The resource allocator 700 queries the announcement 

catalog with the virtual announcement id and the language to 
determine the resource to play the announcement. The 
announcement catalog contains mappings of virtual 
announcements and language to physical announcements. A 

35 physical announcement has an identifier and comprises: 

• the host resource identifier, 

• resource command identifier, 
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paging service. A numeric or alphanumeric message can be 
sent to compatible types of radio pagers. 

3. 4 Vj -f.ial Network 
5 Referring to Figure 53, a virtual network 800 consists 

of a set of directories which maintain the logical 
associations between users of the network and the 
capabilities which are provisioned for them. Virtual network 
directories provided for this purpose are a Virtual Node 

10 Directory 3300, a Virtual Number Directory 3305, a User 
Directory 33 10, and a Service Dictionary 3315. Additionally, 
each Virtual Network 800 has a unique Virtual Network Id 3 320 
and a Status 3325 for enabling or disabling the Virtual 
Network 800 as needed. 

15 The Virtual Node Directory 3300 provides a collection 

of the Virtual Nodes 310 that are available on the Virtual 
Network 800. The Virtual Number Directory 3305 maintains 
associations between Virtual Network Addresses and Virtual 
Directory Numbers. The User Directory 3310 stores user 

20 profiles which link virtual directory numbers and 
authorisation codes to the services provisioned for a user of 
the network. Services are delivered to a Virtual Network in 
a Service Package. Services are installed and stored in the 
Service Dictionary 3315. 

25 Referring also to Figure 34, the Virtual Network 800 

builds a Profile 3400 for use by the Service Engine 825 in 
delivering a service. A Profile includes a user profile 3405 
and all of its related service profiles 34 10. A Profile is 
obtained from the Virtual Network 800 by use of a 

30 VirtualNetworkAddress , an Authorisation Code, or a Virtual 
Directory Number key. 

3.4.1 Profile 

A profile is a commuting object which contains all 
35 that is known about a particular Virtual Network user that 
may be required to process a call. It commutes between a 
virtual network 600 and its associated service engine 
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2. 4. 2. 1 Virtual Director y Number 

Referring to Figure 27, a virtual directory number 
3 700 is a unique representation of a user on a virtual 
network. A virtual directory number has a virtual network 
5 identifier 3 70 5 and a virtual number 3710. The number is a 
TBCD (Telephony Binary Coded Decimal) encoded digit string. 

3.4.3.2 Virtual Network Adflress 

Referring to Figure 38, a virtual network address 3 800 
10 identifies a station on a particular virtual node in a 
particular virtual network 800. 

3. 4." 4 User Directory 

Referring to Figure 39, user profiles 3405 detail user 
15 related information and the provisionable capabilities for 
each user on a virtual network. User profiles are stored in 
a user directory 3900. User profiles 3405 can be obtained 
from the user directory by use of a virtual directory number 
"3415, an authorisation code, or a user profile id key. A 
20 user profile may be added to the directory 3 900 or one may be 
deleted by adding a null profile with the existing id. 

3. 4. 5 Service Dictionary 

Referring to Figure 40, a service is delivered in 
25 ASN. 1 media format as a service package. The service package 
4000 is the definition of a service. A service package 
specifies the features from which an executable service can 
be installed into a virtual network 800. The association 
between a service package, an installed service, and its 
30 related service profiles is provided by an entry 4010 in the 
service dictionary 4005. 

The service dictionary 4005 stores and maintains these 
service entries 4010. The service dictionary 4005 can locate 
a specified service entry in the dictionary to retrieve the 
35 service and access its related service profile directory 4015 
to retrieve specified service profile(s). 
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Intelligent Network Management System (INMS) 120 for 
collation; 

• audit trails to meet -he requirements specified by 
the network operator; 
5 • where relevant, conformance to relevant charging 

requirements for exchanges. 

3. 5. 2. 1 Toll Ticker 

Referring to Figure 4 1, the toll ticket 4100 is a 
10 commuting object that maintains call statistics. Services 
generate toll tickets 4 100 and route them to the billing 
system 220. A toll ticket 4 100 contains the following 
information: 

• call identity; 

15 • Chargecard number; 

• account number; 

• call start time; 

• call stop time; 

• originating call infcrmation; 
20 • terminating call information. 

The network interconnect maintains a list of active 
dialogs, and matches the Call Identity 4105 with the dialogID 
of an active dialog to obtain r.ore information on the call. 

The toll ticket 4 100 is routed by the network 
25 interconnect 8 10 to the software encapsulation of the billing 
system in the management system 520. 



3. 6 Network Interconnerr 

Referring to Figure 4 2, the network interconnect 810 
30 contains the connectivity information relating virtual and 
physical nodes. Nodes in the physical network 805 and nodes 
in the virtual network 800 are not aware of each other. 
Therefore, a service running ;r. a virtual network 800 needs 
the network interconnect to find its associated physical 
3 5 node. Likewise, the network interconnect 310 assures that 
dialogs from the physical network 305 arrive at the correct 
virtual network 300. 
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with a particular physical node address. The virtual node 
address indicates the virtual network identity. The SDI 
connectivity information maintains the relationships between 
physical nodes 305 and virtual nodes 310. It is possible to 
5 associate a maximum of two physical network nodes 305 with 
one virtual network node 310, one being the originating node 
and one being the terminating node. A call is handled by a 
virtual network 800 if and only if all the following are 
as 5 erted: 

10 * the physical node address is one that is known; • 

the physical node address is associated with a virtual node 
address ; 

• a valid virtual network can be deduced; 

• the virtual network is active; 

15 

3.6.-4 Physical Node Disc rimination 

Services run with knowledge of only the virtual nodes 
within its particular virtual network 800. Physical network 
discrimination is achieved through the identification of the 

20 physical node address that is associated with a particular 
virtual node address. The physical node address uniquely 
identifies the physical node. The SDI connectivity 

information maintains the relationships between virtual nodes 
and physical nodes. A call is handled by a virtual network 

25 800 if and only if all the following are asserted: 

• the virtual node address is one that is known; 

• the virtual node address is associated with a 
physical node; 

• the physical node is active. 

30 Figure 24 shows the interactions between the 

components of the SDI 200 in applying the above virtual 
network and physical node discrimination. 

3. 6. 5 Connectivity Directory 
3 5 The purpose of Network Interconnect 810 is to maintain 

the connectivity information between the virtual and physical 
networks. The connectivity information is stored in the 
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the application developer' s class becomes an embedded object 
inside the persistent wrapper class. Referring to Figure 25, 
the wrapper class is persistent by inheriting from a 
persistent superclass. The wrapper class is a persistent 
class which contains the application developer' s original 
class. 

3. 3 Loo 

An SDI 200 may also have a log utility which other 
components can use to log activity and event messages. The 
log utility will preferably interface with the UNIX file 
system. 

3. 9 -Process Manageme nt Control 

15 The components of the SDI 200 and services that run 

under its .auspices are all contained within a finite set of 
manageable processes on the target platform. These processes 
can be managed in two ways, i. e. invasively by an operator or 
automatically by heartbeats. In the following, the action 

20 taken by the operator for Process Management Control is 
discussed. Each managed process accepts the following 
stimuli for the purpose of process control: 

• disable (go out of service) 

• enable (come in service) 
25 • reinitialise 

The following are the different states the process can 
be in depending on what action (shown above) is performed: 

• In Service 

• Out Of Service 
30 • Active 

• Idle 

• Human Busy (hbsy) 

• Machine Busy (mbsy) 

• Initialised/Reinitialise 

3 5 Figure 26 shows the Process Control State Transition 

Diaoram. 
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STEP 44 20: The Service Engine 825 retrieves the 
service from the Virtual Network 800. 

STEP 44 25: The Service Engine 825 resolves the 
references in the service. 

5 

4. 2 Virtual Network Provisioning on the SDT 
Referring to Figure 45, the process for creation and 

deployment of a virtual network 800 on the SDI 200 is as 

follows: 

10 STEP 4500: A Virtual Network 800 is created and 

assigned a VN id. 

STEP 4505: Virtual Network Addresses and Virtual 

Directory Numbers are created and deployed, together with VNA 

and VDN associations. 
15 STEP 4510: User Profiles are created and deployed, 

containing- user data, VDN Service Profile references and any 

necessary " VDN to Service Profile ID" associations. 

4- 3 Ph ysical NetworH/yetworklnterconnect Provisions ncr 
20 on the SDI 

Referring to Figure 46, the process for the above is 
as follows: 

STEP 4600: Virtual encapsulations of switches are 
25 provisioned with switch and trunk IDs. 

STEP 4605: Physical Nodes and Virtual Nodes are 
declared and provisioned to the Network Interconnect 810. 
Physical Node - Virtual Node associations are created and 
deployed 

30 

4. 4 Service (Instance) Provisi oning on the SDI 

Referring tc Figure 47, the service (instance) 
provisioning process is as follows: 

STEP 4 700: A Service Profile is created and deployed 
3 5 to a Virtual Network 800 in the SDI 200. 

STEP 4705: A User Profile is updated with a VDN and 
a Service Profile reference and deployed. 
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A profile can be viewed as the specification of a set 
of attributes describing how a particular service instance is 
to be tailored. Profiles can be global across all networks 
800, for instance network operator defined profiles, network 
5 wide to a particular virtual network 300, or specific to a 
particular user. Where conflict arises, the priority of 
profiles will be first the network operator, then the 
customer (for instance where the customer is an entity 
responsible for bills on benalf of multiple users) and 
10 finally the single user. 

A profile contains: 

1. the virtual network DN, 

2. user attributes, these being default declarations 
of call state that are established when a caller initiates a 

15 call and would include things such as default call type 
(speech, 3- 1kHz, data), 

3. authorisation code, 

4. rule list, 

i 

5. feature lists (originating and terminating). 

20 Looking at the last of the above, every profile has 

lists of features that are available. Features are 

classified as originating features (for example outgoing 
calls barred, originating screening, network side updates, 
restricted access etc) or terminating features (for examcle 

25 incoming calls barred, terminating screen, call forward, 
divert on busy etc). Every profile has two feature lists, 
one of originating and one of terminating features. A 
feature list contains, for every feature, the feature name, 
feature view and feature instance reference. The feature 

30 instance reference points to the provisioned persistent 
feature object instance for this profile. The feature list 
may in practice be empty. 

Feature views are the representation of a call state 
that fulfils the conditions for that feature to be invoked. 

35 The view that a feature requires is specified by the feature 
provider in the feature package. The view for a feature is 
specified in terms of the presence or absence of an element 
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BLACKBOARD TECHNIQUE I N PROVIDING SERVICES 

In the SDI 200, a blackboard is a software object that 
maintains a picture of a call state. The picture changes as 
a call is progressed by the addition, subtraction and 
5 modification of scenes by other objects posting to the 
blackboard. 

Blackboard systems are known, for instance in a 
military context where, for example, a fighter pilot has to 
process incoming data in order to select from a range of 
10 actions. The model is a knowl edge -based system monitoring 
the input and advising the pilot when something interesting 
occurs; e.g. when a real target or threat is identified among 
many dummy target or threats. The financial trader is in a 
similar pos-ition, being the recipient of vast quantities of 
15 data from several information feeds, all of them in need of 
analysis .to determine (a) if anything interesting has 
occurred requiring further analysis, and (b) what the 
appropriate action should be. 

A blackboard system is so called because it imitates 
20 a group of highly specialised experts sitting around a 
blackboard in order to solve a problem. As new information 
arrives it is written up on zhe blackboard where all the 
experts can look. When an expert sees that s/he can 
contribute a new fact based on specialist knowledge, s/he 
25 raises a hand. This might be to confirm or refute an 
hypothesis already on the board or to add a new one. The new 
evidence will now be available to the other experts who may 
in turn be prompted to contribute to the discussion. The 
chairman of the group monitors the experts and selects their 
30 contributions in order, according to an agenda visible on the 
board. Common storage is the blackboard, and the agenda is 
under the control of a specialised inference program. 

If the components of a blackboard system need to 
communicate, there are essentially two methods of achieving 
35 this. Object-oriented systems allow objects to send and 
receive messages which have definite destination objects when 
sent. In blackboard systems the messages are posted to a 
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the control of the SDI 200 and the invocation of feature 
rules, until a quiescent state, resulting in a terminating 
DN, is reached. Translation from the logical world back to 
physical representations occurs when the feature requires 
5 further network interaction or the call is complete and 
requires a terminating leg. 

If it is not possible to identify a user from the 
physical identifiers provided by the virtual network 800, the 
SDI 200 will prompt for an authorisation code. This will be 
10 used to allocate an originating DN so that a profile may be 
retrieved and feature processing may proceed. 

A simplified representation of the retrieval of a 
profile from a service network DN, in this case an 
originating DN, is shown in Figure 27. The feature 2700 
15 registers a view with the blackboard 2705. If there are 
sufficient elements of data present, that is there is a new 
phone number together with the state of ' no reply for the 
_ feature 'Call forward on no reply , then the feature will be 
triggered by the view. Consequently, it will process the 
20 view plus any additional parameters and post back resulting 
scenes to the blackboard 2705. Other features viewing the 
blackboard may then, when invited to focus on their view of 
the call picture, be triggered by the scenes posted as a 
result of another feature processing its view. 
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CLAIMS 

1. A service delivery system, for making services available over a 
communications network, where one or more services selected from a group of 
5 services is made available to at least one network user, wherein said service delivery 
system comprises service provision functionality dedicated to said at least one user, 
the functionality so dedicated comprising a service directory defining the one or more 
selected services available to that user, and a number directory defining a virtual 
network dedicated to that user out of said communications network, within which the 
1 0 services of the service directory are available to that user. 

2. A service delivery system according to claim 1 wherein the service delivery 
system is provided with a stored array of service independent features, and means for 
accessing the service independent features to support provision of a service for one 

15 of said service directories, over a virtual network within which the service is available, 
in response to a call instance relevant to the virtual network. 

3. A service delivery system, for delivering services to users of a 
communications network, one or more services preselected from a group of services 

20 being available to each user, or set of users, wherein the service delivery system is 
provided with the following data structures: 

i) a library of service independent features for use in providing a service 
over the communications network; 

ii) a set of node identifiers for nodes of the communications network; 

25 iii) an array of virtual networks, each virtual network being allocated to a 

user or set of users, and each virtual network being defined in the array by a set of 
virtual node identifiers together with an indication of the service or services allocated 
to its user or set of users; and 

iv) mapping between the node identifiers for nodes of the communications 

30 network and the virtual node identifiers; and wherein the service delivery system is 
further provided with a service execution means which acts on user requests for 
services which can be satisfied within a virtual network to provide execution of the 
relevant services. 
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10. A service delivery system according to any one of the preceding claims which 
presents a common programming interface to elements of the communications 
network in providing, modifying, enhancing or adding a service. 
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B) communicating with the representation of the identified virtual network to 
identify a user profile associated with that virtual node identifier, 

C) communicating with the identified user profile to verify that the requested 
5 service is available, to identify the relevant service package and to obtain any user- 
specific parameters for that service, 

D) communicating with the service package store to identify the relevant 
selected set of units of executable code together with its predefined order, and 

10 

E) communicating with the feature data store to obtain the selected set of 
units of executable code to be executed to provide the requested service. 

1 2. A system according to Claim 1 1 wherein there is provided a service engine 
15 which is common to a plurality of, or all of, the virtual network representations. 

13. Asystem according to either one of Claims 11 or 12 wherein the service 
engine additionally executes the selected set of units of executable code, applying 
the user-specific parameters, such that the selected service is provided. 

20 

14. A system according to any one of Claims 11, 1 2 or 13 wherein there are 
provided a plurality of service package stores, each being comprised by a virtual 
network representation. 

25 15. A system according to any one of Claims 11, 12, 13 or 14 wherein each 
virtual network representation is structured as data encapsulated in process 
software to provide an object. 



THIS PAGE 



BUWK 



(OSPTO) 



WO 95/23483 



PCT/GB95/00421 




WIS PAGE BWNK 



(USPTOj 



WO 95/23^83 



PCT/GB95/00421 



4/24 



m 
o 



o 
o 

CO 



CD 



o 



03 



CO 

to ii 
>* "O 

CL < 



CD 
O 



03 



9 S3 

CO i- 

>> TJ 
C TJ 
CL < 



— TT 

03 CD 

O o 
to m 

>s II 

£d 



o 
o 
o 

CD 
00 
CM 

ii 

*t 
Q 



0) 
TJ 
O 



03 
O 
to 



o 
o 
o 
o 
-d- 

CO 
II 
*t 

O 



o 

+ s 

© CM 
o OJ 

O ^ CO 

^ JI II 
n — I =*fc 



CM 
C\J 
CL 
00 
GO 



TJ- 
Tf 

CD 
CO 

TT 

o 



3fc 
CD 
CD 




W/SP/1GE BLANK 



(USPTD; 



WO 95/23483 



PCT/GB95/00421 



6/24 
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